  <body>
    <h2>Priority Simulation Suite</h2>

    <?php
        include 'form_simconfig.html';
    ?>

    <p>You should define a Virtual Host pointing at the /simulation directory</p>
    <p>Bear in mind that simulations involving large numbers of requests are very
       processor intensive and can take some time to run.
    </p>
    <p>The Simulator is designed to run for a single user at a time.  Who knows what
    would happen if two simulations are run simultaneously.  Implosions I imagine.</p>
    <p>A scenario may depend on version-specific schema.  There are no guarantees that
    a given scenario will work if the installed version differs from that used to
    generate the scenario.  There is no automated process for upgrading a scenario.</p>
    <h2>Running a Pre-defined Simulation</h2>
    <p>You will require a a real configuration file in order to run Saved Scenarios.  Specify the hostname of an Admin installation  on the Simulation home page under Simulation Configuration.</p>    <p>You will require a target database and user with insert/drop/delete priveleges in order to run Saved Scenarios.  Specify these on the Simulation home page under Simulation Target Database</p>
    <p>Php must have zlib enabled for uploading and downloading scenarios</p>
    <h2>Creating a new Simulation</h2>
    <p>The following directories must be writeable.</p>
        <ul>
        <li>/var</li>
        <li>/simulation/data</li>
        <li>/simulation/tmp</li>
        <li>/simulation/SavedScenarios</li>
        </ul>
    <p>For the datepicker to work you need to create a simlink in the /simulation folder
       : ln -sf ../www/admin/js/jscalendar calendar
    </p>
    <p>After saving a new scenario, refresh the menu of Saved Scenarios by clicking on the SavedScenarios link in the left frame.</p>
    <p>The version used to create the scenario is recorded in the &laquo;scenario name&raquo;.php file.  You may experience database errors if the schema used by your current installation differs from that used when creating the scenario.</p>
    <h2>How It Works</h2>
        <ul>
        <li>The Simulation Suite attempts to recreate a live ad delivery and prioritisation  situation.</li>
        <li>It does this by filling a database with core zone & campaign data which is set up by a user and saved as sql commands in a .sql file. All tables in the target database are dropped and recreated using /etc/tables_core.mysql.sql</li>
        <li>While creating a scenario the sims.<host>.conf.php is used, when running a scenario the &laquo;host&raquo;.conf.php file is used.</li>
        <li>Initialisation takes place before each request: global variables declared, global (fake) datetime is set, cookies are unpacked, counters (for capping etc.) are incremented using MAX_cookieUnpackCapping() and the cookie cache is emptied</li>
        <li>Delivery engine output, including cookies and headers, are stopped during simulation. Cookies are 'faked' by manipulating the global cookie array.</li>
        <li>Each request is mimicked by calling the MAX_adSelect() function with user-defined parameters which have been stored in a .php file.  Currently, only a single type of request is used throughout the simulation.</li>
        <li>After each request the result is recorded, success or fail, and if a beacon is present in the delivered ad a call to the logging script, lg.php, is made.  Cookies are packed / flushed and the time is incremented by an hour.</li>
        <li>At the end of each iteration (hour), the data_summary_ad_hourly is updated withe delivery results and the values are reported.  Then an instance of OA_Maintenance_Priority_AdServer invokes method updatePriorities.  When the priority engine has finished the simulation reports the new priorities from ad_zone_assoc</li>
        </ul>
    <h2>Wish List</h2>
    <ul>
    <li>Upgrade scenarios</li>
    <li>Import core data and request sets</li>
    <li>Utilise existing raw data</li>
    <li>User defined reporting</li>
    </ul>
  </body>
</html>